
Animation 385
• Calculating new layouts during animation: When we change a style attribute that affects
the size or position of a component, React Native usually re-calculates the entire layout of the
UI. This calculation happens on a native thread, but is still an expensive calculation that can
result in choppy animations. In this chapter, we’ll learn how we can avoid this by animating
the transform style attribute of a component.
• Re-rendering components: When a component’s state or props change, React must de-
termine how to reconcile these changes and update the UI to reflect them. React is fairly
efficient by default, so components generally render quickly enough that we don’t optimize
their performance. With animation, however, a large component that takes a few milliseconds
to render may lead to choppy animations. In this chapter, we’ll learn how we can reduce re-
renders with shouldComponentUpdate to acheive smoother animations.
• Communicating between native code and JavaScript: Since JavaScript runs asynchronously,
JavaScript code won’t start executing in response to a gesture until the frame after the gesture
happens on the native side. If React Native must pass values back and forth between the native
thread and the JavaScript engine, this can lead to slow animations. In this chapter, we’ll learn
how we can use useNativeDriver with our animations to mitigate this.
Complex control flow challenges
When working with animations, we tend to write more asynchronous code than normal. We must
often wait for an animation to complete before starting another animation (using an imperative API)
or unmounting a component. The asynchronous control flow and imperative calls can quickly lead
to confusing, buggy code.
To keep our code clear and accurate, we’ll use a state machine
85
approach for our more complex
components. We’ll define a set of named states for each component, and define transitions from
one state to another. This is similar to the React component lifecycle: our component will transition
through different states (similar to mounting, updating, unmounting, etc), and we can run a specific
function every time the state changes.
If you’re familiar with state machines, you might be wondering how our state machine
approach will differ from normal usage of React component state. React state is an implicit
state machine, which we often use without defining specific states. In our case, we’re going to
be explicit about our states, naming them and defining transitions between them. Ultimately
though, we’re just using React state in a slightly more structured way than normal.
If you’re not familiar with state machines, that’s fine. We’ll be building ours together as we
go through the chapter. Even if you’re not familiar with the term “state machine,” the coding
style will probably look familiar, since we’ve used it elsewhere in this book already (e.g. the
INPUT_METHOD from the “Core APIs” chapter).
85
https://en.wikipedia.org/wiki/Finite-state_machine